A database can be considered as a multidimensional space (mD-space) where each axis corresponds to an attribute and each object occupies a point in that space. Attribute values may be finite or infinite; continuous, discrete ordinal or discrete nominal. Take, for example, an object 10 as shown in FIG. 1, where each vertex 12 represents one of five attributes. In this case, the object has a value for each attribute, as shown by the lines 14 linking the object to each of its attribute values. However, it should be seen that objects need not be valued for all attributes and this can be represented by omitting a line 14 for such null attributes.
Conventional relational databases store information in a plurality of tables (relations) with each table containing one or more objects and each object containing one or more attributes. Selecting objects in a database corresponds to identifying a subset of objects in the mD-space by specifying one or more conditions within a query. A common form of specifying a query on such databases employs a Structured Query Language (SQL). SQL queries generally take the form:
Select Attributes from Relations where Conditions
Where a database comprises many tables linked together through a complex network of index fields, a database query may become quite complex involving, for example, INNERJOIN expressions. Often applications which link to databases do not expose a user to having to specify a complete SQL query, rather they take input from the user in a simple manner, for example, getting the name of the person they wish to find using a text entry field. This Condition is then inserted into a query where the Attributes which are to form the resultant report and the Relations from which information is drawn for the query are pre-defined by a programmer.
The resultant report is itself usually a relation, again comprising a number of objects conforming to the conditions and having the attributes specified in the query. The relation is then rendered so that it can be displayed on the screen in a suitable manner for example as a table or as a graph.
The resultant report can be thought of as a notional curve in the mD-space connecting all the objects 101 . . . 10z belonging to the subset identified by the query, FIG. 2, and moving through the report is equivalent to navigating along that curve. Nonetheless, because the report is static, should the user not find the required information, they must backtrack to amend the original query before being presented with a new report.
It will be seen, however, that the user often does not have all the right information to define the best possible query initially. Thus, the user submits a query, looks at the results, modifies the query, gets the new result, and so forth. So, to get closer to the desired result requires resubmitting another query which means losing time and it also means that both the original query and the original report are lost.
Query-by-Example (QBE) is a well known method for constructing a database query graphically, again removing the user from needing to learn and write SQL. Using QBE, a user essentially draws an example table comprising the attributes involved in the query and sets attribute values according to the required conditions. The example table is then analyzed, a structured query generated and fed to the database to produce a report.
It is known using a QBE interface to take a report resulting from a first query and use this report in turn as an input for generating a second or subsequent query, for example, Information Server produced by Verity, Inc. For more information see “verity.com”. Each subsequent report, however, still replaces a both previous query and its associated report when generating a new report.
An attempt to move within the results of one query to form another query has been proposed in a visual thesaurus produced by Plumb Design, Inc. For more information see “plumbdesign.com/thesaurus/”. It should be seen, however, that in this case that the report only includes one and only one attribute type, ie synonym, and the query one and only one condition, ie the search word.
It is an object of the present invention, to enable a user to locally move around a specific object in a multi-attribute type database space, according to one or more selected conditions, to provide fine tuning of the result obtained in a report.